GeoScript in Action: Part 3

Soumya SenguptaIn first part of this series we explored GeoScript basics, sliced and diced some solar intensity data, and created several visualizations.  In the second part, we scripted a Web Processing Service (WPS) using the Python implementation of GeoScript. This script suggests the sunniest possible drive inside your current state based on your location and the number of stops you want to make. In this post, we will put together a simple web application that allows you to interact with the WPS service.

Goals of the Web Application

Using the web application, a user should be able to specify a starting point (either by clicking on a map or by using the browser’s geolocation capabilities) and the maximum number of sunny spots the user wants to make on the journey. The web application should then interact with the WPS to determine sunny spots based on the inputs provided. Finally, as an added feature, the web application will determine a route for the journey that starts from the origin and stops at the sunny spots.

User Interface

The web application user interface (UI) is designed to be pretty simple. The following figure shows the major components:

GSBlog3UI.png

The steps the user has to follow are provided on the right-hand side. The results are shown in the different sections below that and on the map. The map itself has typical controls like a pan-zoom bar, a pan button, a drag box based zoom, mouse position based coordinate notifier and layer attributions.

Application Design

The web application is built using HTML5, JavaScript, and CSS. Major aspects of the application, like the interaction with the map and the WPS client, are implemented using OpenLayers 2 (version 2.13.1). The routing is implemented using the MapQuest Open Directions Service. The UI was stitched together using jQuery, Font Awesome, and elements from the Map Icons Collection. The base map used in this application is provided by OpenStreetMap.

Implementation

The code of the web application can be found here and consists of an index.html page, a JavaScript file (js/gsblog3.js), and a CSS file (css/gsblog3.css). As expected, the single web page defines the UI elements while the CSS file makes them look good and the JavaScript file controls all the interactions.

The critical part of the JavaScript code is the interaction with the WPS server. The following code snippet, specifically those surrounding the OpenLayers.WPSClient class, shows how it is done:

// The 2 inputs to the WPS process.
var origin = new OpenLayers.Geometry.Point(startingPoint.lon, startingPoint.lat);
var waypoints = $('#stops').val();

// The WPS server needs to be specified. CORS restrictions apply.
// Bypassed by using ProxyPass directives on local Apache HTTPD.
var wpsClient = new OpenLayers.WPSClient({
    servers: {
         wpsserver: 'http://localhost/geoserver/wps'
    }
});

// Details of the WPS interaction.
wpsClient.execute({
    server: "wpsserver",
    process: "py:solar_wps",
    inputs: {
        origin: origin,
        waypoints: waypoints
    },
    success: function(outputs) {
        $.event.trigger({
            type: 'wpsClientExecuted',
            output: outputs
        });
    }
});

Using WPS

As you might recall, the WPS process that we created in previous post requires two inputs: the origin (what we call the starting point in the UI) and the number of waypoints (the number of sunny stops in the UI). After collecting those, the code proceeds to define the WPS client to the WPS server. In this case, the WPS server is hosted locally by a Geoserver instance with the WPS plugin. The WPS client then executes the request against the WPS process and handles the response.

If the web applications is viewed in Google Chrome with Developer Tools activated, the WPS request and the response can be seen. The following figures show a sample request-response combination.

Sample Requestrequest.png

Sample Response (truncated)

response.png

Another thing to note is the fact the points returned by the WPS may contain duplicates. So, if the user asks for five waypoints, the WPS will return five points but there might be only two unique points. To make the output more meaningful, the JavaScript code provided only works with unique points.

External Services

As is typical in many modern web applications, delivering different functionalities within the application requires the ability to communicate with external services. In this case, the application (running off an Apache HTTPD server) needs to communicate with the WPS server and (later on) the MapQuest routing service. In such situations, the web application is generally subject to strict Cross Origin Resource Sharing (CORS) policies. There are various ways to address the restrictions but In this case we chose to configure our local Apache HTTPD with a few ProxyPass/ProxyPassReverse directives.

Web Application in Action

Here a few screenshots showing the site in action.

After selection of starting point by clicking on the map:

screenshot1.png

After running the WPS and the route by clicking the Create Journey button:

screenshot2.png

Our Professional Services team works side-by-side with your team to help you make the most of your technology investment. Contact us to learn more!

 

EmailTwitterFacebookGoogle+tumblrLinkedIn

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>